[レポート] Data Vault Modelling on Snowflake #SnowflakeDB

10万ボルト！！！！

「カスタマーストーリー」を支えるツール特集

#レポート

#セッションレポート

#ビジネス・アナリティクス

#ビジネス

#Snowflake

たまちゃん

2020.10.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大阪オフィスの玉井です。

Snowflake社の下記のウェビナーを受講したので、レポートします。

ウェビナー情報

公式情報

概要

From insurance and banking to utilities, gaming to travel, Data Vault is gaining popularity across all industries as a methodology that claims to be the most agile and future-proof for connecting all of your data. Whether you work with complex data models or a plethora of data sources, achieving the potential of your data despite making significant investments in data management and analytics capabilities is a must for modern businesses.

Snowflake has always been on the front line of Agile Data Warehousing. Join our 60-minute session, with industry experts and Snowflake evangelists, to discuss the best practices and ideas that could form a start your new data journey:

Snowflake: the best cloud data platform for Data Vault

Datavault UK: new market trends in Data Vault solutions

Panel Q&A: bring your questions!

登壇者

内容の補足

基本的に、下記の2つを説明するウェビナーです。

Data Vaultという新しいデータモデリング技術に対する需要が高まってきている
SnowflakeとData Vaultを組み合わせる方法
- 相性も良い

注意点としては、Data Vaultというデータモデリングの方法に関する基本的な知識がある前提になってますので（Hub、Link、Satelliteという概念が普通に出てくる）、本記事の下部で紹介している、Data Vaultに関するリソースを読んでおくことをオススメします。

レポート

いま、データ分析（基盤）に求められていること

Snowflakeのユーザーのカスタマージャーニーの紹介

Snowflakeを導入したユーザーのうち…
- 9割のユーザーは既存システムからの移行
- 残りは新規立ち上げ（グリーンフィールド・プロジェクト）
導入直後、Snowflakeは（組織の）差し迫った課題の解決に使用される
次に、データ分析の民主化が進む（傾向がある）
- ビジネスの意思決定にデータを使うようになる
そして、説明的データ分析から予測的データ分析へ移行するための基盤になる
- 最終的には、指示的データ分析になる

Snowflake内で使用するべき技術とは

全てのデータを1箇所（Snowflake）に集めることは素晴らしいこと
しかし、いくつかの疑問も出てくる
- どのようなデータモデリング技術を使うべきか？
- 最近のベストプラクティスは？
- 要件に応じて異なってくるのか？

ユーザーはどう考えているか

ユーザーの大半は、複雑なビジネスドメイン（金融、保険、医療など）における複雑なシナリオを（データ分析で）サポートできるようになりたいと考えている
データ分析基盤に対してはスケーラブルであることが求められている
- 迅速にデリバリーされることも求められている
データ分析に対する透明性も求められている
- ブラックボックスではいけない
- どういう影響評価が行われたのか
- レポートの数字はどうやって取得されているのか
上記を満たす方法・技術を考えるにあたって、簡単にできるということも大事

Data Vaultとは

Data Vaultは非常に人気のあるデータモデリング技術の1つになってきている
Data Vaultに対するユーザーの反応は3種類
- 最近データウェアハウスを導入したが、データ管理のベストプラクティスが知りたい層
- Data Vaultを試すべきかどうか考え中な層
- Data Vaultは試しており、Snowflakeでそれをどう活かすかというベストプラクティスが知りたい層
Snowflakeのユーザーのうち、Data Vaultを使っているのは少なくとも300社いる
- 間違いなくもっと増えると考えている

Data Vaultで成功するためには

Data Vaultがわかる人材が必要
- データモデリングの手法を採用するだけではない
- プロジェクト全体を正しく設計・実行できることが重要
自動化の仕組みが必要
- 非常に多くのオブジェクトを管理し、自動化する必要がある
- 価値を生み出すまでの時間の短縮にもなる

Snowflakeの紹介

Snowflakeはクラウドデータプラットフォームである
- 伝統的なDWHのワークロードを実行することができる
- 革新的な機能も随時開発され続けている
データウェアハウス以外の部分も対応できる
- データレイク（の設計パターンのモデル化）
- データサイエンスのパフォーマンスの向上
- データアプリケーション用のバックエンド用
- 部門間でのデータ共有（またはデータマーケットプレイス）
- …など

クラウドデータプラットフォームを支える技術
- ストレージとコンピュートの分離が本質
3つの主要クラウドプロバイダー上で利用可能
- AWS
- Azure
- GCP
クロスクラウド（マルチクラウド）の計画に適応できる

SnowflakeはAgile Data Platformである

スライド右側に載っているたくさんのロゴについて
- Snowflakeと連携できるサードパーティ製品
Snowflakeは全ての操作をコードで操作できる
- データベースや仮想ウェアハウスの設定など
- バージョン管理ができる
- CI/CDが回せる
- つまり、システム開発ライフサイクルを早くすることができる
データのモデリングについて
- どの方法がいいかというのは、ユーザーの要件による
- この後も話に出てくるが、それはSnowflakeの観点から話しているということに留意してほしい

SnowflakeでData Vaultを実現するベストプラクティス

ワークロードの分離

ワークロード別に仮想ウェアハウスを分けるべき
- データサイエンス系などは、部門別に分けるユーザーもいる
- 分けておくと、ワークロード同士で競合することがない

仮想ウェアハウスのスケーリング

仮想ウェアハウスはいつでもスケールアップ（ダウン）ができる
最初は100行のロードしかしなかったが、急に100万行のロードが必要なった場合
- 運用中にそのまま仮想ウェアハウスをスケールアップすることができる
- SLAへの対応も容易
仮想ウェアハウスはいつでもスケールアウトすることができる（マルチクラスター）
- 自動化することも可能
仮想ウェアハウスの実体はAWSのEC2
- だから内部でノードを作成することは簡単
自動マルチクラスターは、Data Vaultを採用するにあたって鍵となる機能

Data Vaultのデータロード

Data Vaultの利点の1つは、並行でデータロードができること
- 段階を踏んでロードする必要がない（依存関係がない）
伝統的なアプローチであるディメンジョナルモデリングは段階を踏んで順番にロードする必要がある
- 例えば、ファクトテーブルを構築する前にディメンジョンをロードする必要がある
Data Vault パターン1も同じ問題がある
- 主キーがintegerのサロゲートキー
- Hub Satsをロードする前に、Hubをロードする必要があった
- Hub間のLinkを構築する前に、全てのHubをロードする必要があった
Data Vaultの典型的なロードパターン（パターン2）の場合…
- ハッシュキーはMD5かSHA256
- Snowflakeはナチュラルクラスタリングキーがあるため、ハッシュキーを使う必要はない
- Hub、Link、Satellite、あらゆる種類のデータを並行でロードすることができる

仮想ウェアハウスをうまく使ってData Vaultを実現する

データのストリーム毎に仮想ウェアハウスを用意するのが良い
- Hubが少ない場合は、それに合わせたサイズにできる
- 多くのSatelliteがある場合、マルチクラスタで並行ロードさせる
- 大規模なCDCが行われている場合は、大きめのサイズにする
丁度いいサイズを探すのは、Snowflakeの醍醐味みたいなところがある
- 何でもかんでも「ロードを早くするためにはMサイズにしないといけない」わけではない
- 最小のHubやLinkで検証をはじめることができる
ユーザーによっては1000個近くのHubがあるところも
- SnowflakeはMPPである
- 仮想ウェアハウスのマルチクラスタを利用してSLAを満たす
- 負荷に応じて自動スケールアウトするので楽
仮想ウェアハウスに関して、一度設定してしまえば、後は何もしなくてよい
- 最初はバッチ処理っぽく定期的なロードを想定したが、後からニアリアルタイムなロードを求められても大丈夫

Data Vaultと半構造化データ

Snowflakeは半構造化データ（JSONとか）をそのまま取り扱える
- variantという型にそのまま入れることができる
スライドのクエリはvariant型を直接参照している
- 名字を取得している
- 名字はJSON内のキーにあたる
これを使用して、Data VaultでいうSatelliteを構築できる

Snowflakeであれば、データソースがほとんど半構造化データでも、Satelliteが構築できる
下記のようなSatelliteを作る
- Hubキー
- ロード日時
- レコードソース
- variant
JSONデータを上記のSatelliteに入れるだけで「スキーマオンリード」が実現可能
- JSONを予め解析する必要がないため、費用対効果が高い
- これを用いたビューを作っておけば、それがBusiness Vaultとなる
- データマートの構築を待たずして、JSONファイルから必要な情報を引き出せる

事例

カルフォルニア州にあるオンラインチケット販売をしている会社
- スライドにうつっているのはこの会社の実際のデータ
JSONデータが入ってくる「オムニレイク」というものがある
Snowflakeにデータレイクを構築した
- 全てのデータを「raw staging area」と呼称するvariantにロードする
- そこからHub、Link、Satelliteを構築し、ビジネスキーを取り出す
- variantにロードしたデータをSatelliteに保存し、Business Vaultレイヤーに移動、ビューを作成する
- それを多少処理してデータマートを作る
これらの処理を行っている仮想ウェアハウスは全てXSサイズ
Webのログデータをニアリアルタイムで連携中
- 顧客にSnowflake上のデータ分析を提供している
担当者曰く「コード量を95%減できた」
- JSONを解析するためのPythonコードが不要になったから
- Snowflakeにロードしてビューを作るだけ
これらはSnowflake以外のアーキテクチャではできない

このスライドは先程と同じユーザーの別のビュー
- 全てLinkがある
- 黄色がデータの属性（Satellite）
ロード日時、タイムスタンプ、variantをキーとして継承している

Data Vaultの市場動向

データ分析（基盤）に対する需要

ここからは、データ分析に関する最新のトレンド等についてお話する

顧客ベース全体でデータ分析に対する需要が高まっている
- より高いパフォーマンス
- より洗練されたデータの使い方
- これらの需要は時間とともに高まっている
多くのユーザーはレガシーなデータウェアハウスを使っている
- レガシーなデータウェアハウスでは需要に追いつけない
- この格差は拡大する一方である
最近、レガシーなデータウェアハウスの機能が落ち着いてきてしまっている
- これが格差をさらに加速させている

この格差を埋めるためには新しいソリューションが必要
- クラウド型のソリューションが求められている
- スケーラブルなアーキテクチャが求められている
これらを検索すると、SnowflakeやData Vaultに行き着く

Eckerson Group - Data Analytics Consulting Research
- Nine Trends That Will Reshape Data and Analytics in 2020
- 「2020年はData Vaultの年になる」と予測
- 新型コロナウィルスのデータ分析の影響で、Data Vaultは2021年に拡張されるとも予測

マッキンゼーもData Vaultについて言及
- How to build a data architecture to drive innovation--today and tomorrow | McKinsey
- 「データモデルが拡張可能であることを保証する」
- 「将来的にデータの要素を最小限の労力で追加や削除ができるようになる」

データ分析のトレンドについて、8つに分けて詳しく紹介する

迅速かつ安全なクラウドへの移行

レガシーなシステムは、タールボールのようなもの
- 完全に結合されている
- 紐解くのが非常に難しい
- クラウドへの移行時に多くの問題、リスク、不確実性が出てくる
Data Vaultはインクリメンタルビルドを提供する
- レガシーなスタースキーマからはじめて、徐々に移行することができる

ラピッドプロトタイピング

ビジネスのスピード的に、レガシーシステムのリファクタリングを待っている余裕は無い
- レガシーなデータウェアハウスは新機能の開発に追いついていない
- 非常に長い設備投資プロセス
- 「まずはやってみないと成果はわからない」
Snowflakeは従量課金なので、スモールスタートに最適
dbtvaultというツールもオススメ
- dbtvault
- 無料
- これを使って、将来的なフルスケールのデータウェアハウスを構築するための資金調達プロセスをサポートするためのエビデンスを構築することが可能

データプラットフォームの一部としてのデータレイク

データレイクを構築しているユーザーの多くが、期待した結果が得られていない
- 「データスワンプ」を構築してしまっている
- データレイクが制御不能に陥っている
- つまり、データ自体は大量に保存できているが、それをレポート用に統合する等ができていない
ハイブリッドアーキテクチャを採用して解決する
- Data Vaultを永続的なステージングエリアとする
- それを元にデータマートを作成する
- MDMやデータカタログでデータマネジメントを補完する
上記の方法のうち、MDMやカタログ以外は、Snowflakeで全て完結できる

リアルタイムなデータ連携

昨今、リアルタイムに近い状態のレポートが見たいという需要が強まっている
- 「昨日までの状態」しか見れない等のケースが多い
Snowflakeのあるユーザーの事例
- 元データをSnowflakeに複製する
- StreamとTaskを使って適宜データをData Vaultへ自動的に移動させている

監査（コンプライアンス）

IFRS第17号というものがある
- IFRS（国際会計基準）第17号保険契約 | PwC Japanグループ
- IFRS17を巡るゴタゴタ｜上野　雄史｜note
- 保険会社等はデータの監査に気をつけなければならなくなっている
Data Vaultはデータ監査の面でメリットがある
- メタデータがあるので、データを正確に保持できる
- どのようなデータがどのように提供されているのかがわかる
- ビジネスルールがデータにどのように反映されているか追跡できる

データの保護

データの保護に関する規則が増えてきている
- EU一般データ保護規則 - Wikipedia
- カリフォルニア州消費者プライバシー法（CCPA）の概要 | NTTデータ先端技術株式会社
色々な規則があるが、内容はある程度共通している
- 個人データの取り扱い
- データのマスキングや分離が必要
Snowflakeには動的にデータをマスキングする機能がある
- ロールやユーザーに基づいて特定のデータをマスキングする
Data VaultにはSatelliteという概念がある
- 個人情報（PII）を個別のSatelliteに分割する
- それらを個別のエリアまたはスキームの担当者に配置し、個別のアクセス権を割り当てる
オブジェクトの主キーに個人情報がある場合
- Linkを使用して分割できる
- 匿名化したバージョンと個人情報バージョンに分割する

テストの自動化及びデータの信頼性の向上

テストをちゃんとできなかったユーザーを沢山見てきた
- 時間がなかったから
- 労力がめちゃくちゃかかる（手動のテストとか）
テストの自動化を奨励する
- データウェアハウス自体がテスト可能なようにアーキテクチャを分割する必要がある
Data Vaultは非常にモジュール化されている
- モジュールをテスト可能な構造体で包むことができる
- 各レイヤーのロードそれぞれでテストを行うことが出来る
- それらのテストをコード化して自動化する